第三層從頭到尾只有一個題目：它不知道你的事，所以你要把你的東西給它看。

第 5 篇給的是最土法的做法：把檔案整份丟進去。後面三篇都在處理這個做法撐不住之後的事：第 6 篇講窗口裡該放什麼，第 7 篇拆開檢索怎麼把那幾段找出來，上一篇量它找得準不準。

今天回到起點，問一句很多人心裡一直有的話：

「那份 300 頁的產品手冊，我整本貼進去不就好了？窗口不是有 100 萬詞元嗎。」

貼得進去。它也會讀。但它不一定會用到你要的那一段。

說穿了，規格表上那個數字保證的是塞得進去，不是它會用到。這兩件事中間隔著一段距離，而這段距離已經有人替你量過了。

30 秒實驗

這個實驗要一份長文件，跟三個問題。

第一步：在 Claude 開一個新對話，拿一份你自己的長文件丟進去，找一句寫在中段的事實，用文件裡的原詞問它。

第二步：把同一個問題換句話問，把原文的關鍵詞全部換掉，改用同義的說法。不要提示它去哪裡找。

第三步：把那句話（或那一段）搬到文件的最後面，再問一次第二步那個問題。

三次的差別就是這一篇的全部內容：第一次問到的是字面，第二次考的是理解，第三次動的是位置。 如果你發現第一次很順、第二次開始猶豫、第三次又變好了，那你剛剛重現的是底下三篇論文量出來的東西。

100 萬是容量，不是能力

先把數字弄清楚。Claude 的官方文件（2026-09-23 查）列的是 100 萬詞元的脈絡窗口，並且附了一個很有用的換算：100 萬詞元大約是 55.5 萬個英文單字，而在 Opus 4.7 換分詞器之前，同樣 100 萬詞元裝得下約 75 萬字。

同一個數字，能裝的東西少了兩成多。窗口的單位是詞元，不是內容，這跟第 4 篇那個「同樣一段文字換代之後多 30% 詞元」是同一件事的另一面。

而 100 萬有多大？第 5 篇算過一份 100 頁的 PDF：文字加上每頁轉成的圖片，最壞約 78 萬詞元。一份報告就吃掉將近八成。

回到開頭那本 300 頁的手冊，照同一個算法：最壞約 234 萬詞元，是窗口的兩倍多；就算它是純文字、沒有圖，照官方給的一頁 1,500 到 3,000 詞元估，也要 45 萬到 90 萬（這幾個數字是我拿第 5 篇那張表自己乘出來的）。

所以那本手冊很可能一開始就貼不進去。 而這還是最好的情況：塞不進去至少會報錯，你當場就知道。

所以「整包塞進去」在很多情況下根本塞不下。但真正的問題不是塞不塞得下。

第 5 篇說過一句話：它沒有「學會」你的文件，那些字只是在你問問題的時候，跟著你的問題一起被送進窗口。 當時那句話用來解釋「為什麼明明上傳了它還是答錯」。今天把同一句話推到 100 萬詞元的規模：字全部在窗口裡，不代表它會用到那幾個字。

規格表回答不了這一題，回答這一題的是基準測試。

在那之前，先把兩條路擺在一起看，因為這一層剩下的內容都在這張表裡：

左邊那一欄什麼都不用管，這就是它誘人的地方。 右邊那一欄是前三篇在做的事，每一格都要你付出東西。所以「窗口變大之後，右邊那一欄是不是就不用做了」，是一個值得認真回答的問題。

大海撈針過關，不等於長脈絡可用

長脈絡最廣為流傳的測試叫大海撈針（needle in a haystack，NIAH）。定義直接引論文的原話就好：RULER 說它「檢驗的是從一大段干擾文字（haystack）裡取出一段資訊（needle）的能力」，並且「已被廣泛採用來評估長脈絡模型」；NoLiMa 的描述一樣。很多「支援 N 萬詞元」的宣傳圖，量的就是這個。

不過有件事值得先知道：這個測試不是從理論或論文長出來的。 它出自 Greg Kamradt 在 2023 年 11 月放上 GitHub 的一支腳本（2,385 星，到 2026 年 6 月都還在更新），專案自己的說明就一句話：「在不同脈絡長度下做簡單的檢索，量準確率」。一支開源小工具變成了整個產業的宣傳圖，而真正把它的極限量出來的，是後面這幾篇論文。

RULER（Hsieh et al., COLM 2024）第一句話就把它定位了：這種單純的檢索式測試，只反映長脈絡理解裡很表面的一層。作者做了一套可以調長度與難度的合成基準，除了大海撈針的各種變形，還加上多跳追蹤與彙總這兩類「不只是在文字裡搜東西」的任務，然後拿 17 個長脈絡模型、13 種任務去跑。

結果是這樣：

在原版的大海撈針測試上幾乎滿分，但長度一拉長，幾乎每一個模型的成績都大幅下滑。

更具體的一句：這些模型全都宣稱支援 32K 詞元以上，但只有一半在 32K 這個長度還維持得住像樣的表現。論文另外分析了宣稱支援 200K 的 Yi-34B，結論是長度與任務複雜度一拉高，進步空間還很大。

宣稱的長度是規格，維持得住的長度是能力。 這兩個數字從來沒有人保證它們相等。

把字面線索拿掉，分數就掉下來

大海撈針還有一個更隱蔽的問題：那根針通常跟問題用字重疊。模型不必真的理解，只要比對字面就找得到。

NoLiMa（Modarressi et al., ICML 2025）就是為了這件事設計的：它把針換成跟問題幾乎沒有字面重疊的句子，逼模型去推那個沒有寫出來的關聯。13 個宣稱支援 128K 以上的模型，在短脈絡（1K 以內）都表現得很好，然後：

作者的解釋是：沒有字面線索的時候，注意力在長脈絡裡更難把相關的東西抓出來。

讀到這裡你應該有既視感。第 6 篇講可分心性的時候說過，模型判斷「相關」很大一部分靠的是詞面上的相似，而不是語意上的可用；上一篇講向量檢索的時候，同一件事換到了距離那一端。現在它第三次出現，而且這次是在「什麼都不用檢索、整包塞給它」的情況下。

這不是檢索特有的毛病，是這整套東西的底層行為。

而它在知識庫上的長相你大概見過：整份手冊貼進去，照著標題問它答得出來，換成同事平常的講法問同一件事，它就開始含糊。你以為問題出在你沒講清楚，其實是那段文字跟你的問法沒有字面重合。

想通這件事，兩個常見的困惑就解開了：

• 為什麼有時候「換個問法再問一次」就答對了？ 不是它想通了，是你第二次剛好用到了文件裡的字。
• 為什麼示範的時候都很順，給同事用就狀況百出？ 因為你問問題的時候，腦子裡記得原文怎麼寫。

同樣一句話，放在哪裡也算數

第 6 篇欠了一筆帳：那一篇把位置偏誤列成腐化的第四種機制，說「位置效應有多大、在什麼長度開始明顯」留給後面專門的一篇。就是這裡。

那篇論文叫 Lost in the Middle（Liu et al., TACL 2023），做法很乾淨：拿兩種需要在輸入裡找出正確資訊的任務（多文件問答、鍵值查找），只改變正確答案擺放的位置，其他都不動。

結論是：成績在資訊放在開頭或結尾時最好，放到中間就明顯掉下來，連那些專門標榜長脈絡的模型也一樣。

這件事的實用價值比前面兩篇都直接，因為它是第 6 篇說的四種機制裡唯一你調順序就能緩解的：重要的東西放頭尾，不要塞在中間。

而「中間」是誰？整份塞進去的時候，是你那份文件的第 40 到 60 頁；走檢索的時候，是排在第三、第四塊的那幾段。同一個現象，兩種做法都躲不掉。

所以基準測試到底在量什麼

三篇論文，三種量法，三個不一樣的結論，而它們量的是同一批模型。這件事本身就是這一節要講的。

先把詞分清楚。EvalEval 這個社群在他們的文件裡把名詞定義成這樣：單一基準是用一個資料集測一種能力、出一個分數（例如 MMLU，約 1.5 萬題、57 個科目）；複合基準是把一堆基準聚合成一個總分（例如 BIG-Bench，超過 200 個任務）；指標則是那個拿來打分的數值本身。

他們掛在同一個專案頁上的那篇論文（Batzner et al., 2026，48 位作者）要解決的問題，正好是你讀排行榜時踩的那個坑。摘要裡的兩句話：

結果散落在排行榜、論文、部落格、評測框架的日誌與自建程式庫裡，格式互不相容。

不同的評測框架，對名義上相同的評測會產生分歧的分數，metadata 也記得不一致。

同一個基準，換一個人跑，就不是同一個數字。 所以「某模型在某基準拿幾分」這種句子，少了「誰跑的、怎麼設定的」就幾乎沒有意義。

這件事也有人在動手解。EvalEval 這個社群維護了一個公開的程式庫（MIT 授權，2026-09-23 查，README 自己連向上面那篇論文），裡面是一份 JSON schema，規定一筆評測結果要帶哪些欄位才有得比，另外附了從 Inspect AI、HELM、lm-eval-harness 的日誌轉成那個格式的轉換器。

你不一定要用他們的格式，但可以拿那份欄位清單當檢查表：你上次量出來的那個分數，記下模型版本了嗎？記下提示詞、題目、是誰跑的、什麼時候跑的嗎？第 4 篇那十題和上一篇那組配對，半年後你自己看得懂嗎？讀別人的基準需要這些欄位，你自己的分數也一樣。

這三篇論文合起來，給了一套讀基準測試的方法，而且不限於長脈絡：下次看到「Claude 在某某評測拿幾分」這種句子，同一套問題照問。

還有幾句要自己打折。這三篇量的都不是你的東西：RULER 用的是合成資料，NoLiMa 用的是自己設計的題目，Lost in the Middle 用的是公開的問答任務，沒有一份是你的手冊、你的合約、你的工單。它們也都不是今年的模型。

但方法比數字耐放。 換句話問、改變位置、拉長長度，這三個變因你今天就能在自己的文件上動，而那正是 30 秒實驗那三步在做的事。

這一層的代價

長脈絡不是檢索的替代品，是另一組成本。 塞得進去的東西每一輪都要重送，每一輪都以輸入詞元計價（第 4 篇那把 count_tokens 現在就是拿來量這個的）；而上面三篇量到的是，塞進去也不保證它用得到。

「反正窗口很大」是這一層最貴的一句話。 它讓你跳過切塊、跳過評估、跳過出處，然後在某個 32K 的對話裡開始收到說得很篤定卻對不上的答案，而你沒有任何一個數字可以拿來對照。

規格數字不會騙你，但它也不回答你的問題。 100 萬是容量上限；RULER 量的是它在合成任務上的維持程度；NoLiMa 量的是拿掉字面線索之後的落差；Lost in the Middle 量的是位置。沒有一個是你的文件、你的問題、你的使用者。

所以第三層那個題目沒有捷徑。 「它不知道你的事」這個洞，補法只有一種：在它回答之前，把該知道的字放進去。窗口變大只是讓你能放的東西變多，沒有改變「放進去的東西它不一定用得到」這件事，而那正是第 6 篇到上一篇三篇在處理的事：挑得準一點，位置擺對一點，然後量它有沒有真的挑到。

所以長文件我現在的做法是這樣：

到這裡工具就齊了：知識庫、切塊、向量、重排序、出處、召回率，加上今天這把「別人量到哪裡」的尺。下一篇要把它們放進同一個請求裡，然後結算這一整層的帳。

這一篇多了什麼，又多付了什麼

多了什麼能力：你看得懂長脈絡的宣傳數字了，也知道那個數字不能替你的知識庫背書。規格表講的是容量，RULER 講的是維持得住的長度，NoLiMa 講的是拿掉字面線索之後剩下什麼，Lost in the Middle 講的是位置，而重要的東西該放頭尾。

多付了什麼代價：一個大到讓人想偷懶的數字。窗口越大，「先全部塞進去再說」越誘人，而這一篇三份量測說的都是同一件事：塞得進去跟用得到，中間隔著一段沒有人替你量過的距離。

下一篇

這一層學到的東西，要怎麼排進同一個請求裡？

系統提示、範例、檢索回來的那幾塊、使用者的問題，四種東西擠在同一個窗口裡，誰前誰後不是風格問題：快取邊界、訊噪比、出處粒度都綁在順序上。下一篇把它們組起來，順便把第三層這六篇欠的帳一次結清。

延伸閱讀

• RULER: What's the Real Context Size of Your Long-Context Language Models?（Hsieh et al., COLM 2024）：大海撈針只測到表面，17 個模型、13 種任務，宣稱 32K 的只有一半撐得住。
• NoLiMa: Long-Context Evaluation Beyond Literal Matching（Modarressi et al., ICML 2025）：把字面重疊拿掉之後，32K 就有 11 個模型掉到基準的一半以下。
• Lost in the Middle: How Language Models Use Long Contexts（Liu et al., TACL 2023）：只改位置不改內容，中段最吃虧。
• Every Eval Ever（Batzner et al., 2026）：不同框架對名義相同的評測會給出不同分數。
• evaleval/every_eval_ever（MIT）：那份 schema 與轉換器本身。拿它的欄位清單當自己評測紀錄的檢查表。
• Models overview（Claude 官方文件）：100 萬詞元的窗口，以及換分詞器之後同樣的詞元裝得下多少字。